This is a mystery to me, largely because Novell had made innovations relevant to the Internet "way back" in 1991. Even at that time, the Novell NetWare platform supported TCP/IP and was Internet ready. Today, Novell is still very much in the running. Web servers and other baseline Internet applications continue to be written for the Novell platform. And, interestingly, Novell may measure out to be as secure as any of its counterparts.
Since that time, NetWare has undergone some major changes. And, although it is not really secure in its out-of-the-box state, NetWare has some substantial security features. Control of what services run on what port is just as incisive in Novell as it is in UNIX. The system is, in fact, nearly identical. For those of you who are considering stringing your Novell network to the Net (which is now a popular practice), I suggest getting some background in TCP/IP. Many excellent Ethernet administrators familiar with IPX are less confident about their TCP/IP knowledge. This is where standards really shine through and assist the administrator. TCP/IP is negotiated in a similar fashion on almost every platform.
In NetWare, the file that governs your service is SYS:ETC\SERVICES. This file contains a list of services that you will be running from out of your intranet to the Internet at large. It is the equivalent of the /etc/services file in UNIX. It is from this file that you pick and choose your services, which may include TFTP, FTP, and Telnet. In this respect, a Novell network running TCP/IP could be scanned in the same fashion as a UNIX box. The SYS:ETC\SERVICES file is one to watch closely. Misconfigurations there can lead to security problems.
The discretionary access controls in NetWare are also formidable. In fact, Novell's control of the system is quite granular. It extends, for instance, to time-based restrictions. A user's access can be restricted to certain hours of the day and certain days of the week. Users' passwords are subjected to aging and there are at least rudimentary controls to reject passwords that are either too short or those that have been used before.
Control over directories and files is good. For example, the following controls can be placed on directories:
Here is an interesting bit of trivia: Using the Novell NetWare operating system, you can actually restrict the physical location at which a user can log in. That is, you can specify that John can only log in from his own station. If he proceeds to another computer, even just 6 feet away, he will be unable to log in. In order for you to do this, however, you must specify that all users are restricted in the same manner.
The Novell NetWare network environment offers fine security. (It is not perfect, but demonstrates advanced security techniques, even going back to Novell NetWare 3.x.) Novell NetWare 4.x is a very strong platform and has become popular as a WWW server platform.
NOTE: NetWare also has provisions for a hierarchy of trust. That is, you can assign managers to each section of the LAN and assign a group of people to each manager. Thus, NetWare can be used to quickly and efficiently map out relationships of trust and authority that closely (if not precisely) parallel the actual levels of trust and responsibility between those within your organization.
The flip side of this is that we have not yet seen Novell handle the void. In closed network situations, Novell has proven to be an excellent networking platform. The levels of security it provides will foil all but the most studious cracker or hacker. Novell is just now getting a taste of the real outside world. It may not be long before we see Novell security advisories floating around the Internet. Later in this chapter, you will get a chance to see at least one flaw found only two months prior to this writing. It is a hole that could allow a remote exploit. You'll also learn about other exploits as we briefly look at the security of Novell.
One point I should explain here is why Novell holes have not surfaced in the same way that UNIX holes have. The Novell NetWare environment is vastly different from the UNIX environment. NetWare is used primarily in business settings. Many accounting firms, law firms, and medical practices use NetWare as a networked platform. DOS-based programs run well in NetWare, so you can use it for record keeping, accounting, and billing.
NetWare also provides an attractive enough interface, and it is surprisingly lightweight considering the wonderful networking job that it does. However, NetWare users and UNIX users are disparate. NetWare users characteristically access DOS-based programs through the shell. The shell provides a suitable menu interface. You simply move the arrow down the list of choices and fire. It is a point-and-shoot type of environment from that standpoint. Thus, although there are undoubtedly thousands of developers that may work their craft on a Novell NetWare network, the majority of NetWare users never really come into contact with the operating system level. To them, the underlying framework is largely invisible.
In contrast, UNIX users regularly have contact with dozens (if not hundreds) of commands at the operating system level. Because UNIX is a developer's platform (with that development deeply rooted in the C programming language), UNIX users are more intimately familiar with the nature of their operating system, its flaws, and its virtues. On this account, hard-core analysis of the UNIX operating system is constantly under way. This process is not only undertaken by developers for UNIX vendors, but also by the people who rely on this strange operating system each day. As the general knowledge of an operating system increases, so does the specific knowledge regarding its holes.
Such in-depth analysis in NetWare is confined primarily to the developers who created it. Their source code is proprietary and therefore, the computing community has no reliable way of knowing what flaws, if any, exist in the NetWare operating system. True, there may be fragmented efforts here and there to attack the binaries of that operating system, perhaps searching for buffer overflows or other, lower-level, problems.
The future will tell us all about NetWare, though, because it has now survived that one giant step to the Internet. NetWare users now want their networks strung to the Net. And, as I said at the beginning of this chapter, Novell had provisions for strong TCP/IP support five years ago.
Throughout this chapter, I will take a look at NetWare security. Again, the purpose of this book is not to cover one operating system extensively, but rather, to prepare the user for general Internet security. By the time you reach the last quarter of this book, I will be making references to all the operating systems covered up until that point, often not only in the same chapter, but in the same paragraph. I have tried to design this book so that by the time you reach that point, you will be well prepared.
In short order, then, let's have a look at this old but revolutionary operating system.
In NetWare, the supervisor account is passwordless on a fresh installation and remains so until the supervisor assigns a password. (In other words, the operating system never forces a password.) Moreover, there is a GUEST account created at time of installation. If you do not feel that you will need this account, go into SYSCON and delete it immediately. However, if you envision using this account to provide guest access, assign a password to it immediately.
NOTE: When installing Slackware versions of Linux, for example, the process completes by you booting to a login prompt. The first time you log in, you log in as root without a password. It is left to the user to assign a password to the root account. Not all UNIX-based platforms work this way. For example, when you're installing SunOS by hand, one of the last options it requests is what the root password will be. Similarly, Red Hat Linux registers a password before the first boot load. This policy is probably a wise idea.
There are different forms of spoofing. Typically, when we think of spoofing, we have in our minds the notion of IP spoofing across the Internet. Certainly, this is the most popular kind of spoofing among crackers because of the press coverage that followed Kevin Mitnik's arrest. How-ever, there are different types of spoofing. Here, I am referring to hardware address spoofing.
In Chapter 28, "Spoofing Attacks," I address IP spoofing attacks. However, it will suffice here to write that in 1985, at Bell Labs, it was determined that spoofing was a viable procedure. A paper was posted to the Net on this subject. It was four pages or so, describing how such an attack might someday be implemented.
Spoofing in the NetWare environment is not impossible; it is just difficult. Most crackers advise that you can change the hardware address in the NET.CFG file. However, it might not be as easy as this.
The node address is generally hard-coded into the Ethernet card itself. If you have such a card lying around the office, take a look at it; the address is generally posted directly on the face of the card (a little sticker or perhaps even letters burned into the board itself). Some cards have jumpers that allow you to alternate the IRQ and ROM address settings. Some boards also allow you to alter the node address of the card via software. That is where the spoofing comes into the picture.
NOTE: The NET.CFG file contains parameters that are loaded on boot and connection to the network. This file includes many options to alter the configuration by hand (which is mighty useful because conventional configurations sometimes fail to "come out right"). To supplement this, changes may be made directly to the interface using this file. Options include number of buffers, what protocols are to be bound to the card, port number, MDA values, and, of course, the node address.
The popular way to spoof is by altering the address in the NODE field in the NET.CFG file. In this scenario, you assign the node an address belonging to another workstation. However, severe problems could result from this if you were to initiate a session using the identical hardware address of a workstation also logged on. This could potentially crash the system, hang the machine, or cause other trouble on the wire.
If this technique is to be truly effective, the cracker must devise a way to temporarily "kill" or anesthetize the machine from which he is claiming to originate. This may not be a problem, depending on the circumstances. Perhaps the other machine has been turned off for the night. If so, the cracker has a wide open field for experimentation.
This refers only to hardware address spoofing in an Ethernet setting. However, some Novell NetWare networks are running TCP/IP on the inside. TCP/IP spoofing from inside a Novell NetWare network is a different matter and much will depend on how much information the cracker can glean about the network.
NOTE: In order for this type of attack to work, many variables must be just right. For example, if there are any network interfaces between the attacker and the target, this may not work. Say the packets have to cross a hub and there is some hardwire scheme that manifests the path between the target and the machine the cracker is claiming to originate from. Under this scenario, the spoofing attack will fail miserably.
Fortunately, in most instances, such an attack will not be effective against a Novell NetWare network. Following version 2.0a, passwords passed during the login process were encrypted. Therefore, a sniffer attack would be largely a waste of time.
Any attempt to capture passwords on a Novell NetWare network would probably be via a keystroke capture utility. There are only a limited number of these and they all have to be at least on the same interface or machine as the target. Thus, securing each workstation for key capture utilities is a fairly straightforward process.
NOTE: An attacker could technically capture encrypted passwords and transport these elsewhere, perhaps to his home or office. There, he could eventually crack these using a brute-force password utility. However, there are other more immediate avenues to try. Running a sniffer could be a complicated process on a NetWare network. Many workstations are liable to be diskless clients, leaving the cracker no place to hide his bounty. (And realistically, just how much sniffed traffic can fit on a floppy that already has boot and network loading files on it?)
Obviously, keystroke capture utilities won't be found on diskless clients (unless loaded onto the floppy), so your field of investigation is narrow. The time your search will consume is increased only by the hard drive size and directory structure depth of the workstation you are examining. You can assume that the utility is probably a hidden file, probably named something different from what it was originally named. (In other words, you will not be looking for files such as Gobbler or Sniffer. Crackers and hackers may write programs with dramatic, pulp-fiction names, but when they go to deploy those tools, more innocuous names are in order.)
There are several ways you can search. One is by checksum/size. Another is to use a utility such as grep. Most of these cracking utilities contain within the code some string of unique text. (Frequently, crackers put a slogan, a nickname, or a comment within the code.) Using grep, awk, or other utilities with powerful regular expression search capabilities, you can attempt to identify such files, which may be masquerading as normal system files or documents.
It is true that sniffers are almost pointless (too much effort and too great a risk) with respect to Novell NetWare passwords in versions higher than 2.0a. However, if your network houses older file servers, the default password encryption scheme must be disabled, according to Novell NetWare Version 3.11 Installation Guide (Novell, Inc.).
NOTE: Crackers suggest that keystroke capture utilities be placed somewhere in the path. This allows the utility to be remote, but still capture the needed data. Thus, if you were searching for such a utility, you would start with all directories declared in the path statement. This statement may be oddly formed, too, depending on whether the machine is a diskless workstation. If it is not a diskless workstation, take a look at the autoexec.bat.
This poses quite a different situation. Passwords on those interfaces will be moved across the network in clear text. This is a fact well known to crackers. Under such circumstances, a cracker would benefit greatly from utilizing a packet sniffer. If you are currently in such a situation, I suggest you attempt to transplant that information elsewhere and upgrade the OS or to disconnect that file server from any portion of a network already reasonably believed to be safe from sniffing attacks.
Cross Reference: Spooflog is available (along with the source code) at http://www.users.mis.net/~gregmi/.
Cross Reference: Crack is available at http://www.mechnet.liv.ac.uk/~roy/freeware/crack.html.
Cross Reference: Snoop is available at http://www.shareware.com/code/engine/File?archive=novell-netwire&file=napi%2fcltsdk1e%2fsnoop%2eexe&size=102625 .
The problem with these utilities, of course, is that they take an enormous amount of time. Moreover, if the supervisor has enabled intruder detection, an intruder detection lockout (IDL) will occur. IDL works by setting a "threshold," which is the number of times that a user can forward incorrect login attempts. Added to this value is the Bad Login Count Retention Time. This time period (which defaults to 30 minutes) is the block of time during which bad login attempts are applied to the IDL scheme. So if an incorrect login is received at 1:00 p.m., monitoring of subsequent logins on that account (relative to IDL) will continue to look for additional bad logins until 1:30 p.m. To compound this, the supervisor can also specify the length of time that the account will remain locked out. This value defaults to 15 minutes. IDL is therefore a very viable way of preventing brute-force attacks. If these options are enabled, a brute-force cracker is worthless against the Novell NetWare platform.
TIP: If you are new to security and have been handed a Novell NetWare network, you will want to enable IDL if it hasn't already been. Also, you should check-- at least twice a week--the audit log generated from that process. (The events are logged to a file.) You can access that log (which is really the equivalent of /var/adm/messages and syslog in UNIX) by changing the directory to SYS:SYSTEM and entering the command PAUDIT.
One reported way to cause a denial-of-service attack on NetWare (3.x and possibly 4.x) is to capture a network printer and attempt to print an absurdly large file. This overflows the SYS volume and causes the machine to crash. Naturally, this would require not only physical access to an internal machine, but also an account there. However, in large organizations, it is entirely possible that malicious individuals may exist--individuals who may be secretly working for a competitor or just plain crackers who love to see a system go down. This is a relatively low-priority attack, as the machine can easily be rebooted and the problem solved.
A brute-force attack in this case is a program that automates the process of trying hundreds (or sometimes thousands) of passwords on a given server.
The attack technique is a form of spoofing and is dependent on many things. (In other words, this is neither an easily implemented nor widely known technique.) The following are the limitations on the attack:
Cross Reference: A complete explanation of Miller's process is available at http://geek-girl.com/bugtraq/1996_3/0530.html.
These types of exploits for NetWare are rare.
One thing that you will readily notice about the Novell NetWare platform is that most of the methods used to crack it require some local, physical access. In all other respects, Novell NetWare is a strong platform, primarily because of its advanced access controls.
However, my earlier point is still relevant. NetWare has not yet run the gauntlet. As more NetWare servers are erected on the Net, we may see a shift.
Cross Reference: WSetPass 1.55 is available at http://ourworld.compuserve.com/homepages/nick_payne/wsetpass.zip.
Cross Reference: WnSyscon 0.95 is available at ftp://ftp.novell.com/pub/nwc-online/ utilities/wnscn095.zip.
Cross Reference: BindView EMS is available at http://www.bindview.com:80/products/nosadmin3.html.
Cross Reference: SecureConsole is available at http://www.serversystems.com/secure.htm.
Cross Reference: GETEQUIV.EXE is available at http://mft.ucs.ed.ac.uk/novell/techsup/freedos.htm.
Books
NetWare Security. William Steen. New Riders Publishing. 1996.Magazines and JournalsNovell's Guide to Integrating NetWare and TCP/IP. Drew Heywood. Novell Press/IDG Books Worldwide. 1996.
NetWare Unleashed (Second Edition). Rick Sant'Angelo. Sams Publishing. 1995.
A Guide to NetWare for UNIX. Cathy Gunn. Prentice Hall. 1995.
NetWare LAN Management ToolKit. Rick Segal. Sams Publishing. 1992.
The Complete Guide to NetWare 4.1. James E. Gaskin. Sybex Publications. 1995.
Building Intranets on NT, NetWare, Solaris: An Administrator's Guide. Tom Rasmussen and Morgan Stern. Sybex. 1997.
The NetWare to Internet Connection. Morgan Stern. Sybex. 1996.
NetWare to Internet Gateways. James E. Gaskin. Prentice Hall Computer Books. 1996.
Novell's Guide to NetWare LAN Analysis. Dan E. Hakes and Laura Chappell. Sybex. 1994.
Novell's Four Principles of NDS. Jeff Hughes. IDG Books Worldwide. 1996.
NetWare Web Development. Peter Kuo. Sams Publishing. 1996.
The NetWare Connection.
Inside NetWare.
Institute of Management and Administration.
© Copyright, Macmillan Computer Publishing. All rights reserved.